In many applications it is desirable to save the content received from restricted broadcast or encrypted multicast to local files for subsequent replays. The locally saved files should ideally be protected by a Digital Rights Management (DRM) system to prevent unauthorized usage. It is a great challenge to combine conventional DRM with conventional restricted multicast/broadeast since they use different mechanisms to accomplish different goals, and the conventional mechanisms tend to be mutually exclusive. The access control characteristic of restricted multicast/broadcast is designed to ensure that users not belonging to a premium group are unable to access the privileged content. Thus, a new content encryption key is generated each time there is a change in the group membership. These key changes can even occur in the middle of playing the live content. Access control in restricted multicast/broadcast can be achieved by a key distribution mechanism such that only the parties currently belonging to the premium group can receive the content decryption keys, which are then used to decrypt the encrypted multicast/broadcast content. Thus, key distribution mechanisms that support access control in restricted multicast/broadcast are needed.
In a conventional DRM system, on the other hand, a content object is usually encrypted with a single encryption key to avoid the complexity of key generation and management.
There are at least two conventional straightforward ways to use multicast and DRM together, but both have serious drawbacks. The first straightforward solution, referred to as the direct recording method, saves encryption blocks received via multicast/broadcast directly to local storage. A user needs to acquire a license from a license server to play the saved content. A license according to this conventional technique has to contain all the content encryption keys associated with all the possible combinations of the saved encryption blocks. This means that a license may contain multiple, even a substantial number of content encryption keys. The license server has to store and track all the content encryption keys used in multicast/broadcast in order to deliver necessary keys required for DRM protection across all the users.
The second straightforward solution, referred to as the transcryption technique, works in a similar manner as a transcoder to compression: a recipient transcrypts the encrypted multicast/broadeast content into DRM encrypted content. In this conventional technique, the recipient first decrypts the encrypted multicast content, using multiple content decryption keys, and then re-encrypts the content using DRM encryption, in which a single content encryption key is used for each saved file. In addition to the disadvantage of computational overhead during the transcryption, the security of the system is also compromised. The recipient is required to perform the content packaging that a content publisher normally does in a conventional DRM system. Since users are not trusted in the threat model of DRM applications, more client modules have to be protected against hacking and reverse engineering. In this conventional technique, a conventional DRM content encryption key also needs to be acquired from the license server by the recipient before re-encryption.
Thus, conventional techniques to provide DRM for restricted multicast/broadcast result in some serious drawbacks. DRM as applied to the conventional “direct recording” technique of storing encrypted multicast content introduces the drawback of requiring complex key management and the drawback of sending a cumbersome number of keys per license to a client. DRM as applied to the conventional “transcryption” technique of storing encrypted multicast content into a DRM format necessitates the drawbacks of requiring prior possession of the DRM key, intensive computational overhead, and introducing the user's machine as an essential middleman in what is supposed to be a secure DRM process for managing the digital rights of the same user.